Proposal: OpenSocial Mobile extension

[yoichiro]

Hi folks,

We would like to propose the new spec for Mobile OpenSocial
applications. This spec has already been implemented by Mixi platform
in Japan, and many applications based on the spec have already been
published for many users.

Proposal: OpenSocial Mobile extension:
http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en.xml

mixi Apps Mobile system overview:
http://developer.mixi.co.jp/appli/appli_mobile/lets_enjoy_making_mixiappmobile/mixiappmobile_summary?lang=en

I have already introduced this proposal to a few members who attended
OpenSocial Union event.

The wiki page regarding a mobile apps has already been created by
Mark. Two devices are mentioned in the page. One is the full Web
browser supported devices, and another one is the WAP/Partial Web
browser supported devices. The scope of this spec is for cell-phones
based on WAP which a JavaScript and an iframe tag are not supported,
thus the target of this spec is the second one.

Add support for mobile devices:
http://wiki.opensocial.org/index.php?title=Add_support_for_mobile_devices

I believe that this spec will bring a diversity of OpenSocial
applications. We would like to hear your feedback on this proposal.

Thanks,
-Yoichiro Tanaka (mixi, Inc.)

[goosemanjack]

Good to see all the work on this front. We've been working on this as
well at MySpace, but have taken a more simplistic approach.

We're implementing by creating a pre-defined view called
"mobilecanvas". I like that your proposal is addressing WAP issues to
some degree. We also should flesh out the required container feature
subset, if we're not requiring a full container to be available.

We have some concerns with the process flow requirement identified in
"Compliance"
http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en.xml#rfc.section.3

In our app development and rendering pipeline, we work from a
publishing and review model. This helps us weed out malware and
protect our users. Making pulling from original source a core
compliance requirement is not something that we can support.

The invite friends URL is an interesting idea, but I'm not sure its a
necessary extension.
http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en.xml#rfc.section.7.3.1
We already have the script function "requestShareApp" and
<os:PeopleSelector>. Perhaps a better approach could be to extend
OSML to have a simple tag-based invite UI.

<os:AppInvite />

Then the container could choose the appropriate implementation, be it
a link/URL or a rich dialog.

The "Approach for Full Web Browser Supported Devices" section uses
views in a manner that causes a collision with sub-views
http://wiki.opensocial.org/index.php?title=Add_support_for_mobile_devices#Approach_for_Full_Web_Browser_Supported_Devices

It's very difficult to find the subview documentation in the spec, but
a reference to it is here:
http://wiki.opensocial.org/index.php?title=OpenSocial_Views_Developer%27s_Guide#Subviews

From an implementation standpoint, its going to be simpler to create
predefined views as full views:
"mobilecanvas", "mobilehome", "mobileprofile", "wapcanvas" It's also
questionable in my mind if all these views are even necessary. The
mobile experience is such that we're unlikely to wish to give up real
estate on another user's mobile profile to any app. Perhaps we could
implement with main views: "mobile", "wap" and allow for multiple
surfaces to be simulated as subviews for containers wishing to support
it.
--
clc

On Jun 19, 6:33 pm, yoichiro <yoich...@eisbahn.jp> wrote:
> Hi folks,
>
> We would like to propose the new spec for Mobile OpenSocial
> applications. This spec has already been implemented by Mixi platform
> in Japan, and many applications based on the spec have already been
> published for many users.
>

> Proposal: OpenSocial Mobile extension:http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en...
>
> mixi Apps Mobile system overview:http://developer.mixi.co.jp/appli/appli_mobile/lets_enjoy_making_mixi...

>
> I have already introduced this proposal to a few members who attended
> OpenSocial Union event.
>
> The wiki page regarding a mobile apps has already been created by
> Mark. Two devices are mentioned in the page. One is the full Web
> browser supported devices, and another one is the WAP/Partial Web
> browser supported devices. The scope of this spec is for cell-phones
> based on WAP which a JavaScript and an iframe tag are not supported,
> thus the target of this spec is the second one.
>

> Add support for mobile devices:http://wiki.opensocial.org/index.php?title=Add_support_for_mobile_dev...

[Christopher Laffoon]

Thanks for commenting on the WAP mobile-extension spec from Mixi as well as the Mobile Views extensions documented on the OpenSocial wiki.

As is briefly mentioned on the wiki, one of the important things we need to start figuring out is how we integrate this WAP mobile-extension spec with the non-WAP mobile views support we are discussing.  The simplest way I believe, which was mentioned in the email below, would be building distinct mobile view constructs for WAP and for non-WAP devices.  When the WAP view content is selected to be rendered and the container has chosen to implement this WAP extension spec, then the container would render the gadget based on the procedures outlined in the extension spec. 

If we did not want to tie the WAP specific specification to the view name itself, another option would be to define a new content type called "WAP", so that it is clear when rendering should be done according to this additional WAP extension spec vs. the core gadget specification (for HTML or URL gadgets).  I have not completely thought through the implications of a new content type, so this option might not even be viable.

In regards to how complex we make the mobile view constructs, for WAP and non-WAP devices, we should also be thinking through what this might look like for tablet devices.  I completely agree that there might not be a huge need for having more than one view-type for a small mobile device, but I could definitely see the value for a table device in having multiple views that are different than for a desktop or notebook.  I believe it would be wise for us to design with this flexibility in mind whether we designate views for device-types by concatenating the device-type with the view name (i.e. "mobilecanvas"), or by new top level views (i.e. "mobile.canvas"), or by some other delination (i.e. "mobile:canvas").

From a performance perspective, I am glad you mentioned not requiring a full container to be available on a mobile device.  One possible way we could implement this would be allowing a gadget developer to not only specify required features for the entire module, but also for certain contents and views within that module.  For example, you might not want the new pub/sub feature for the mobile views of the gadget, but you would want it for the desktop canvas and home views.  We should definitely continue thinking about this requirement and how it should apply to all the different views, not just mobile views.

I'll try to capture some of the thinking in these areas on the external wiki so we can continue collaborating with that as our reference point.

Thanks!
- Chris

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[yoichiro]

Hi goosemanjack,

Thank you for your comment!

> The invite friends URL is an interesting idea, but I'm not sure its a

> necessary extension.http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en...

> We already have the script function "requestShareApp" and
> <os:PeopleSelector>. Perhaps a better approach could be to extend
> OSML to have a simple tag-based invite UI.

Yes, I understand your mention. Actually, I was at a loss whether to
include it in this spec or not. The invite friends URL function should
be moved to the appendix section as an unnecessary extension. Of
course, I think that OSML is also a good approach.

The reason why we are supporting the approach of the url replacing is
that we want to provide developers more flexibility regarding the
design element. In the case of using OSML, developers can not
customize its look and feel. But developers can choice the UI for the
link to navigate the page to select friends. For example:

The link UI:
<a href="invite:frinds">Invite!</a>

The button UI:
<form action="invite:friends">
<input type="submit" value="Invite!" />
</form>

And, the scope of our proposal is for a WAP phone. Therefore, we can
not use the script functions like "requestShareApp".

> Then the container could choose the appropriate implementation, be it
> a link/URL or a rich dialog.

I agree and intend to add this mention to the proposal draft doc.

> estate on another user's mobile profile to any app. Perhaps we could
> implement with main views: "mobile", "wap" and allow for multiple
> surfaces to be simulated as subviews for containers wishing to support
> it.

If a lot of people think that the word "mobile" means the rich device
which provides full functions like a smart-phone (ex. iPhone,
Android), the view name "mobile" may be mistake in our proposal and I
think that I should replace its name to "wap". How do you think about
this? In Japanese, the word "mobile" usually means WAP phones...

Thanks,
-Yoichiro

On June 22, 2:04am, goosemanjack <cc...@myspace.com> wrote:
> Good to see all the work on this front. We've been working on this as
> well at MySpace, but have taken a more simplistic approach.
>
> We're implementing by creating a pre-defined view called
> "mobilecanvas". I like that your proposal is addressing WAP issues to
> some degree. We also should flesh out the required container feature
> subset, if we're not requiring a full container to be available.
>
> We have some concerns with the process flow requirement identified in

> "Compliance"http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en...

>
> In our app development and rendering pipeline, we work from a
> publishing and review model. This helps us weed out malware and
> protect our users. Making pulling from original source a core
> compliance requirement is not something that we can support.
>
> The invite friends URL is an interesting idea, but I'm not sure its a

> necessary extension.http://www.eisbahn.jp/mobile-extension/opensocial-mobile-extension-en...

> We already have the script function "requestShareApp" and
> <os:PeopleSelector>. Perhaps a better approach could be to extend
> OSML to have a simple tag-based invite UI.
>
> <os:AppInvite />
>
> Then the container could choose the appropriate implementation, be it
> a link/URL or a rich dialog.
>
> The "Approach for Full Web Browser Supported Devices" section uses

> views in a manner that causes a collision with sub-viewshttp://wiki.opensocial.org/index.php?title=Add_support_for_mobile_dev...

>
> It's very difficult to find the subview documentation in the spec, but

> a reference to it is here:http://wiki.opensocial.org/index.php?title=OpenSocial_Views_Developer...

[Christopher Laffoon]

Yoichiro and Chris, thanks for submitting and commenting on the WAP mobile-extension spec as well as the Mobile Views extensions documented on the OpenSocial wiki.

As is briefly mentioned on the wiki, one of the important things we need to start figuring out is how we integrate this WAP mobile-extension spec with the non-WAP mobile views support we are discussing.  The simplest way I believe, which was mentioned in the email below, would be building distinct mobile view constructs for WAP and for non-WAP devices.  When the WAP view content is selected to be rendered and the container has chosen to implement this WAP extension spec, then the container would render the gadget based on the procedures outlined in the extension spec. 

If we did not want to tie the WAP specific specification to the view name itself, another option would be to define a new content type called "WAP", so that it is clear when rendering should be done according to this additional WAP extension spec vs. the core gadget specification (for HTML or URL gadgets).  I have not completely thought through the implications of a new content type, so this option might not even be viable.

In regards to how complex we make the mobile view constructs, for WAP and non-WAP devices, we should also be thinking through what this might look like for tablet devices.  I completely agree that there might not be a huge need for having more than one view-type for a small mobile device, but I could definitely see the value for a table device in having multiple views that are different than for a desktop or notebook.  I believe it would be wise for us to design with this flexibility in mind whether we designate views for device-types by concatenating the device-type with the view name (i.e. "mobilecanvas"), or by new top level views (i.e. "mobile.canvas"), or by some other delination (i.e. "mobile:canvas").

From a performance perspective, I am glad you mentioned not requiring a full container to be available on a mobile device.  One possible way we could implement this would be allowing a gadget developer to not only specify required features for the entire module, but also for certain contents and views within that module.  For example, you might not want the new pub/sub feature for the mobile views of the gadget, but you would want it for the desktop canvas and home views.  We should definitely continue thinking about this requirement and how it should apply to all the different views, not just mobile views.

I've captured some of the thinking in these areas on the external wiki so we can continue collaborating with that as our reference point.

Thanks!
- Chris

[goosemanjack]

As I chew it over, I'm liking the idea of specifying WAP as a content
type. The content type is the trigger that determines the major code
path for handling and rendering the included content. All other view
designations currently make the assumption that final output will be
HTML. I think it's wise to talk at a high level how we want to handle
WAP in the gadget, but I don't want to get too bogged down since we're
unlikely to support WAP in the short term and will be recommending WAP
support as an optional item in the spec.

Smartphones are the more immediate concern for us. My feeling is that
we want to keep the solution as skeletal as practical at this stage.
So long as the basic framework is designated, I think we can let
different containers and developers explore the best approaches to the
myriad of issues likely to be encountered on mobile devices. Then we
can feed the best solutions back into the spec via the extension
process.

WRT tablets, I'm not sure we need to do too much at the spec level
yet. Tablets should consume web pages correctly enough for most
cases. I want to see more data on usage patterns of tablet devices, as
well as what solutions are developed for the web at-large before we
paint the spec into a corner on this one.
--
clc


On Jun 24, 5:45 am, Christopher Laffoon <claffoon....@gmail.com>
wrote:

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>
> > .

[yoichiro]

Hi goosemanjack,

Thank you for your comment again.

I think that the application container can know the device type
according to the user-agent request header, and the content-type
header should not be used for determine the device type. At least, the
content-type values of both Japanese cell-phone (not smart-phones) and
PC browsers are same.

In our proposal, actually, the method to recognize the device type is
not mentioned. The cause is that I think that the method is not one.
For example, an IP address range, an user-agent header may be used. Of
course, the method to determine whether the user's device is a smart-
phone or not will be included it, too.

In fact, as you said, it makes the assumption that the final output
will be HTML in our current proposal. Of course, I think that the
application container can change the process by checking the response
content-type header value. However, I believe that most cases are
covered by supporting XHTML only in the current cell-phones. If you
have other cases, I would like to know the use-case you have.

I'm sorry when missing the point of the argument.

Thanks,
-Yoichiro

[Mark W.]

I'd like to take a quick checkpoint of where we are in the
conversation to try and get agreements on a few basic points.
Once we agree on these below, Chris L. or I will then update the wiki
page to reflect this, and we'll build off of these. I've got a couple
of other questions on tablets and the container that I'll take to
different posts.

* We want to keep the initial pass very simple and add only enough so
that gadget developers have a basic hooks they need that will simplify
the gadget development.

* We need to keep WAP and Smartphone (what we've been calling
"mobile") distinct. Not all containers will support WAP, e.g. MySpace.
The goal is to have a consistent programming model for all the
devices.

* The use of content type is not a valid approach to determining the
device because in the Japanese market, WAP devices and browsers are
the same content type.


So far so good?

-Mark W.

> ...
>
> read more »

[Mark W.]

WRT tablets...

I'm not sure the issue here is the browser that is on the device. That
is, I agree that the use case for supporting someone using Safari on
the iPad is very similar to someone using Safari on a notebook. Maybe
there are some advantages to indicating a different view type, but not
sure.

What I'm less certain about are the "hybrid" apps, those that have a
native "shell" that then load the browser inside of them. These are
then "skinned" to get native look and feel. We are seeing this use
case more and more because what customers want is a single programming
model and application, and then "generate" out to a platform, e.g.
iPhone, Android. This feels slightly different than a hybrid app on a
smartphone because you have access to more real estate.

So, like you, I'm not exactly sure where we'll end up, but given how
insanely fast tablets are taking off, it would be good if we could
figure out a way to provide some capability for developers.

-Mark W.

> ...
>
> read more »

[yoichiro]

To goosmanjack,

I have the thing you should know. It is that our proposal is not a
desk plan.

In Japan, mixi and at least one SNS have already implemented and
published the platforms based on our proposal. And, a lot of users can
already enjoy many applications with the WAP-phone. We have an actual
performance about our proposal, and mixi has already been operating it
for six months.

For example, the current status of mixi is the following:

No. of monthly login users: 13.86 million
No. of users: 19.85 million
Monthly page views: 27.97 billion (WAP-phone only)
No. of apps providers: 460
No. of apps: About 620 (for WAP-phone only)
No. of top 1 app's users: Over 5 million

I would like to let you know the above results. Of course, the actual
result values are each double in all of Japan. I can say that our
proposal has already been fully-stabled.

And, I can understand that the market size of a smart-phone is
becoming big. However, in the world, the market size of WAP-phone has
already been big. In addition, the reach rate of the smart-phone is
only about 10% yet in Japan and a lot of countries. I believe that our
proposal can be happy for more users in the world.

As the result, we should deal with the more big market "WAP-phone",
right?

Of course, I think that the market of the smart-phone is also
important. We are developing the application platform for smart-phones
now, and will be able to feed back the proposal based on the platform
to here.

I would like to hear your thinking about the above. And, if you have
an objective information to judge we should give priority to smart
phone, please let us bring it.

Thanks,
-Yoichiro (mixi, Inc.)

On June 25, 2:45am, goosemanjack <cc...@myspace.com> wrote:

> ...
>
> もっと読む »

[yoichiro]

Hi Mark,

Thank you for your mentions, and LGTM.

I can prepare the wiki to publish and edit our proposal document
together, if necessary. Should I do it?

Thanks,
-Yoichiro

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com.

> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[goosemanjack]

That's exciting to see how deep your market penetration is already.
It seems that your focus is primarily on WAP because that's where the
market is, whereas our focus is on Smart Phones because that's where
we feel the market is going and there's a smaller delta in end user
experience for our developers to design for.

To summarize my baseline position:

* We need a standardized view (or family of views) designated for
smartphone devices
* Limitations should not be prematurly codified in the spec since this
is a rapidly developing space and not yet stable
* Non HTML-based support (i.e. WAP and native-esque device controls)
should at most be an optional item in the spec

Given that you have a proven solution to WAP in the market, we should
continue to follow your lead in this area. The only caveat is that we
make sure no collisions with other parts of the spec occur (subview
handling comes to mind, but I have to re-read your proposal).

To Mark's point about locking down areas of agreement to narrow the
discussion, yes. Lack of recognition of commonly accepted areas early
on is why some of the 1.0 scope discussions seemed to drag on, IMO.

On the other point, could we split the tablet device discussion out
from mobile? Mobile (smartphone) support I see as core, whereas
tablet support I see as extensions or market-driven and left in the
hands of developers. These are likely to be some of the most active
discussions this round, and I don't want them to weigh each other
down.
--
clc

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

[yoichiro]

Hi Chris,

I have just created the page of our proposal draft on the OpenSocial
wiki. Incidentally, I change the name of the spec to "OpenSocial WAP
Extension".

http://wiki.opensocial.org/index.php?title=Opensocial-wap-extension

I intend to start modifying it according to goosemanjack and your
mentions. Please let me know, if I mistook something.

Thanks,
-Yoichiro


On Jun 24, 9:45 pm, Christopher Laffoon <claffoon....@gmail.com>
wrote:

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> > .

[Christopher Laffoon]

Hi Yoichiro,

Thanks for putting the "OpenSocial WAP Extension" proposal up on the wiki. I look forward to seeing the changes you might make.

I hope to update the wiki very soon with the mobile pieces we have agreed upon and the ones we are still discussing.

Thanks,
Chris

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[yoichiro]

Hi Chris, Mark,

I'm thinking a structure of view name for the mobile and wap devices.
We called the view for WAP "mobile", but I have already received some
objections from a few members. We should systematize views to support
all views which include PC, tablets, and etc.

In the talking with you, I found that the word "mobile" means a smart-
phone (iPhone, Android and etc.), not included WAP-phone. But at
least, in Japan, the word's meaning includes both. I think that smart-
phones and WAP-phones should be divided definitely as different view
names without using the word "mobile". Or the word "mobile" should
have a meaning of a generic name for smart-phones and WAP-phones.

For example, I would like to propose the following definitions. My
favorite is 2.

1) "mobile.full.[Sub view]" (for smart-phones)
"mobile.partial.[Sub view]" (for WAP-phones)

2) "touch.[Sub view]" (for smart-phones)
"wap.[Sub view]" (for WAP-phones)

3) "mobile.touch.[Sub view]" (for smart-phones)
"mobile.wap.[Sub view]" (for WAP-phones)

I think that a tablet device has enough computer resources. Therefore,
an architecture for PC device (use Shindig) can be applied, I guess.
In this case, we don't have to define a specific view name for the
tablet device, right? Because an application container doesn't need to
change the back-end architecture depending on the view name, I think.

How do you think about the above?

Thanks,
-Yoichiro


On Jun 30, 2:20 am, Christopher Laffoon <claffoon....@gmail.com>
wrote:

> ...
>
> read more »

[Bess Ho]

Hi Yoichiro,

I'd like to give my input as mobile developer. First of all, I'd like to introduce myself. I have involved in facebook and open social since their platform launch as a local developer community leader. Lately I have been active in mobile development.

1) "mobile.full.[Sub view]" (for smart-phones)
  "mobile.partial.[Sub view]" (for WAP-phones)

Comment: I think it is best to not use partial b/c it is a very difficult word to guess the definition of "partial" and "full". I will be against this naming convention.

2) "touch.[Sub view]" (for smart-phones)
  "wap.[Sub view]" (for WAP-phones)

Comment: It is better than option1. However touch doesn't cover all smart and feature phones in US. There are many early models like Nokia, Blackberry, Android, SamSung, Window phones don't support touch. The naming convention is not clear it is for mobile.

3) "mobile.touch.[Sub view]" (for smart-phones)
  "mobile.wap.[Sub view]" (for WAP-phones)

Comment: It is the best option as it is clear that it is for mobile. However, US mobile market is very different than the rest of the world. The biggest and most popular social network platforms are found and launched in US. To gain platform and developer support, the standard would need to cover US mobile market.

Touch won't cover all smart phones. Wap won't cover all feature phones. Definition of smart phone is here
http://en.wikipedia.org/wiki/Smartphone

A smartphone is a mobile phone that offers more advanced computing ability and connectivity than a contemporary basic 'feature phone'.^[2] Smartphones and feature phones may be thought of as handheld computers integrated within a mobile telephone, but while most feature phones are able to run applications based on platforms such as Java ME or BREW,^[3] a smartphone allows the user to install and run more advanced applications based on a specific platform. Smartphones run complete operating system software providing a platform for application developers.^[4]

Suggested Proposal:

"mobile.touch.[Sub view]" (for smart-phones)

"mobile.nontouch.[Sub view]" (for smart-phones)
"mobile.feature.[Sub view]" (for feature-phones)

"mobile.wap.[Sub view]" (for WAP-phones)

Feel free to contact me offline.

Bess

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

--
Bess Ho
UI Architect / Developer / Designer
iPhone Developer
Silicon Valley Web Builder (SVWB) Founder

The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

[Christopher Laffoon]

Yoichiro and Bess,

Thanks for continuing the discussion on these view type names for mobile and WAP devices.

I definitely agree with Bess that we should not use "touch" to differentiate between WAP devices.  However, I am not sure whether we really need to have separate views for all the different types of devices, given the view at this point is primarily defining the viewport size.  The exception to this is WAP since this would require a different mechanism.

So, in order to satisfy all these ideas and some suggestions from MySpace, I recommend we use the terms "mobilecanvas" and "mobilewap" for the two different view types.  Using these will ensure it is clear they are both for mobile devices, but clearly calls out the difference in "mobilewap" from other mobile views.

Let me know your thoughts...but, I am seeing this is a decent compromise at this point.

Thanks!
- Chris

[goosemanjack]

I'm still on board with the "mobilecanvas/mobilewap" approach after
all the discussions and proposals to date. As much as anything, it's
because it's a simple solution. IMO OpenSocial has a long history of
being over-engineered, so some simplicity at the onset would be a good
thing.

Comments on the previous proposals:

* The term "touch" is not analogous to a mobile device - consider
Tablet devices, Surface, and the (relatively small, but growing)
penetration of touch displays in traditional laptops

* The term "mobile", as Bess pointed out, really means Smartphone
within the US market, and not a WAP phone, as in the Japanese market.
I suppose "cell" would be the closest designation used commonly when
referring to WAP feature phones in the US market.

Given the rapid advancement and blending of devices in the mobile/
smartphone/tablet space currently (and TV set-top boxes like Google
TV), I think a simple solution that satisfies current needs only is a
sensible approach, at least at the official spec level. After a round
of developing mobile apps in the wild we can revisit this solution and
build on it or throw it out in favor of something extensible (and
complex).

Not sure what this means for Mixi's work. Perhaps we could look at a
bridge solution or an extension to support their more baked-in WAP
model for sites wanting extended WAP support?
--
clc



On Jul 7, 10:00 am, Christopher Laffoon <claffoon....@gmail.com>
wrote:

> Yoichiro and Bess,
>
> Thanks for continuing the discussion on these view type names for mobile and
> WAP devices.
>
> I definitely agree with Bess that we should not use "touch" to differentiate
> between WAP devices.  However, I am not sure whether we really need to have
> separate views for all the different types of devices, given the view at
> this point is primarily defining the viewport size.  The exception to this
> is WAP since this would require a different mechanism.
>
> So, in order to satisfy all these ideas and some suggestions from MySpace, I
> recommend we use the terms "mobilecanvas" and "mobilewap" for the two
> different view types.  Using these will ensure it is clear they are both for
> mobile devices, but clearly calls out the difference in "mobilewap" from
> other mobile views.
>
> Let me know your thoughts...but, I am seeing this is a decent compromise at
> this point.
>
> Thanks!
> - Chris
>

> > A *smartphone* is a mobile phone<http://en.wikipedia.org/wiki/Mobile_phone>that offers more advanced computing ability and connectivity than a
> > contemporary basic 'feature phone<http://en.wikipedia.org/wiki/Feature_phone>
> > '.[2] <http://en.wikipedia.org/wiki/Smartphone#cite_note-1> Smartphones

> > and feature phones may be thought of as handheld computers integrated within
> > a mobile telephone, but while most feature phones are able to run

> > applications based on platforms such as Java ME<http://en.wikipedia.org/wiki/Java_ME>or
> > BREW <http://en.wikipedia.org/wiki/BREW>,[3]<http://en.wikipedia.org/wiki/Smartphone#cite_note-2>a smartphone allows the user to install and run more advanced applications
> > based on a specific platform. Smartphones run complete operating system<http://en.wikipedia.org/wiki/Operating_system>software providing a platform for application developers.
> > [4] <http://en.wikipedia.org/wiki/Smartphone#cite_note-3>
>
> > *Suggested Proposal:*

>
> > "mobile.touch.[Sub view]" (for smart-phones)
> > "mobile.nontouch.[Sub view]" (for smart-phones)
> > "mobile.feature.[Sub view]" (for feature-phones)
>
> > "mobile.wap.[Sub view]" (for WAP-phones)
>
> > Feel free to contact me offline.
>
> > Bess
>

> ...
>
> read more »

[Bess Ho]

I also agree on simple approach. I am not aware of the "mobilecanvas/mobilewap" as I may have missed some threads.

Given the fact that the rapid advancement of all devices, it is best to find the best solution to meet current needs.

I do think we should support Japanese market b/c there are many active WAP phones around the world.

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[yoichiro]

Hi Bess, goosemanjack, Chris,

Thank you for your comments. I have been thinking some method for
making of it more simply. While talking with you, probably I might
lose our original goal.

Originally, our proposal is a new architecture to render your gadget
for cell-phone / wap-phone which is not supported JavaScript / iframe.
Until now, OpenSocial has been supporting two architecture about
rendering a gadget:

* html: render HTML contents written as the body text which a Content
element has on Gadget spec file.
* url: render an external contents specified by the href attribute
which a Content element has without any changes.

Well, I would like to propose the new architecture, I would not like
to propose the new view's structure. In fact, the view name can be
decided by each SNS independently, I think that we should define a
rule for a relation of the view name that SNS decided to the new
architecture. For this, we can use the type attribute of the Content
element.

For example, the new architecture based on our proposal is named
"wap". The Content element can be written as the following:

<Content type="wap" view="..." href="http://your.server.name/path" />

In this case, the view name to be applied the new architecture can be
decided by SNS freely. If some SNSs use a different view name,
developers can write some view names using the delimiter ',' to
support some SNSs at same time by one Gadget spec file. Of course, we
don't need to worry this and that about view names. :)

As my mind, actually, I don't like the name "wap". This architecture
is the rendering phase by a proxy model, and I want to name "proxy" or
"delegate" and so on...

I would like to know your opinions.

Thanks,
-Yoichiro

> ...
>
> read more ?

[Christopher Laffoon]

Hi Yoichiro,

I have been trying to think through all of the implications of these changes.  It seems to me that one problem with specifying the content type for wap, instead of creating a different view name, is that this would not allow a developer to easily declare WAP and non-WAP supported perspectives in the same gadget.  This is because the use of type=URL (and presumably type=WAP) within a content section does not allow any other content sections to specify that view name. 

Thus, we would still need a separate view name for WAP whether or not you use a content-type of URL or WAP.  If you want to support WAP and non-WAP within the same gadget, then the triggering for which one is shown must be by the view name and not the content type.

Have you encountered any of this in your implementation?  I might have missed something obvious, but it seems that which view gets loaded will determine which content type is used instead of vice-versa.

I hope that helps.

- Chris

> ...
>
> read more ?

[Bess Ho]

I can see Chris's views. Perhaps by doing prototype it would help to clarify what options are better.

[Mark W.]

Yoichiro & Bess,

I'm just following up on this thread. I know that we've talked about a
few next steps, but I have not seen anything come forward yet. As we
make progress on 1.1, I'd like to make sure that we don't find
ourselves scrambling at the last minute trying to force something in.

-Mark W.

On Jul 15, 3:31 am, Bess Ho <bess...@gmail.com> wrote:
> I can see Chris's views. Perhaps by doing prototype it would help to clarify
> what options are better.
>

> On Wed, Jul 14, 2010 at 2:10 PM, Christopher Laffoon <claffoon....@gmail.com

>
>
>
> > wrote:
> > Hi Yoichiro,
>
> > I have been trying to think through all of the implications of these
> > changes.  It seems to me that one problem with specifying the content type
> > for wap, instead of creating a different view name, is that this would not
> > allow a developer to easily declare WAP and non-WAP supported perspectives
> > in the same gadget.  This is because the use of type=URL (and presumably
> > type=WAP) within a content section does not allow any other content sections
> > to specify that view name.
>
> > Thus, we would still need a separate view name for WAP whether or not you
> > use a content-type of URL or WAP.  If you want to support WAP and non-WAP
> > within the same gadget, then the triggering for which one is shown must be
> > by the view name and not the content type.
>
> > Have you encountered any of this in your implementation?  I might have
> > missed something obvious, but it seems that which view gets loaded will
> > determine which content type is used instead of vice-versa.
>
> > I hope that helps.
>
> > - Chris
>

> ...
>
> read more »

[Bess Ho]

Hi Mark,

I can't speak on behalf of Yoichiro and/or WAP. I don't program and use WAP device.

I review the workflow on Non-Wap prototype code. It looks fine to me. However there is no playground on latest OS1.1 including this mobilecanvas to see how this work in device. I probably won't be able to build OS1.1 app just to verify this.

Spec also didn't mention much about screen size. Each OS vendor defines their canvas size differently. What are the mini-height, mini-width, default-height, default-width? Going forward what are the possible properties are supported on mobilecanvas? Can we incorporate HTML5 JavaScript navigator.geolocation.getCurrentPosition?

Sorry I just have a lot of questions when you start asking me for my input.

Bess

### Non-Wap & Wap ###
Non-Wap (MobileCanvas Code)
https://issues.apache.org/jira/secure/attachment/12451229/OpenSocial_Mobile_Shindig_Patch.txt
https://issues.apache.org/jira/browse/SHINDIG-1403

Wap
http://wiki.opensocial.org/index.php?title=Opensocial-wap-extension

### General ###
SVN doc
http://opensocial-resources.googlecode.com/svn/spec/proposals/1.1/mobileViews/Core-Gadget.xml#gadgets.views.ViewType

Mobile
http://wiki.opensocial.org/index.php?title=Add_support_for_mobile_devices

### HTML5 Geo ###

<script language=”Javascript”>

if (navigator.geolocation) {

navigator.geolocation.getCurrentPosition(function(position) {

ZoomToLocation(position.coords.latitude, position.coords.longitude);

});

}

else {

if (document.getElementById(“GeoAPI”)) {

document.getElementById(“GeoAPI”).innerHTML = “I’m sorry but Geolocation services are not supported by your browser – use Firefox 3.5″;

document.getElementById(“GeoAPI”).style.color = “#FF0000″;

}

}

function ZoomToLocation (mylat, mylong) {

if (document.getElementById(“GeoAPI”)) {

//Implement a zoom to location

document.getElementById(“GeoAPI”).innerHTML = “mylat: ” + mylat + “ mylong: ” + mylong;

}

}

</script>

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Yoichiro Tanaka]

Hi Mark,

I'm sorry my response too late because recently I was very busy...
Currently, I'm developing the patch code set for Shindig to support
our wap extension. I intend to complete this task by the end of this
month.

Well, we don't have the conclusion yet whether we should use or not
the type attribute with "wap" value to apply using the wap extension
to one content element. However, I think that the type attribute
should be used, the specific view name (ex. wapcanvas) should not be
used. The code I'm developing now is based on the approach of using
the type attribute.

Give me some time to develop the patch, please.

Thanks,
-Yoichiro

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
>

--
Yoichiro Tanaka
Email: yoic...@eisbahn.jp
Blog: http://www.eisbahn.jp/yoichiro

[goosemanjack]

It seems like both the smartphone and the WAP proposals are maturing
well. Currently they're bundled into a single voting item, which has
caused at least myself some confusion in the past. Could we break
this into two distinct proposals (one for mobile smartphones, one for
WAP) to clarify the discussion?

I'm going off the list currently shown here:
http://wiki.opensocial.org/index.php?title=Spec_Changes#Proposals_for_OpenSocial_1.1:_Current_Status_At_a_Glance

--
clc

On Aug 11, 9:32 pm, Yoichiro Tanaka <yoich...@eisbahn.jp> wrote:
> Hi Mark,
>
> I'm sorry my response too late because recently I was very busy...
> Currently, I'm developing the patch code set for Shindig to support
> our wap extension. I intend to complete this task by the end of this
> month.
>
> Well, we don't have the conclusion yet whether we should use or not
> the type attribute with "wap" value to apply using the wap extension
> to one content element. However, I think that the type attribute
> should be used, the specific view name (ex. wapcanvas) should not be
> used. The code I'm developing now is based on the approach of using
> the type attribute.
>
> Give me some time to develop the patch, please.
>
> Thanks,
> -Yoichiro
>

> ...
>
> read more »

[Yoichiro Tanaka]

Hi goosemanjack,

Yes, I agree your suggestion, and also hope that the mobile proposal
should be divided two proposals. Mark, how do you think about this?

Thanks,
-Yoichiro

[Mark W.]

Yoichiro & Chris (goosemanjack),

This makes sense. I've created another entry here:
http://wiki.opensocial.org/index.php?title=Spec_Changes#Proposals_for_OpenSocial_1.1:_Current_Status_At_a_Glance

-Mark W.

On Aug 12, 8:08 pm, Yoichiro Tanaka <yoich...@eisbahn.jp> wrote:
> Hi goosemanjack,
>
> Yes, I agree your suggestion, and also hope that the mobile proposal
> should be divided two proposals. Mark, how do you think about this?
>
> Thanks,
> -Yoichiro
>
>
>
> On Fri, Aug 13, 2010 at 8:47 AM, goosemanjack <cc...@myspace.com> wrote:
> > It seems like both the smartphone and the WAP proposals are maturing
> > well.  Currently they're bundled into a single voting item, which has
> > caused at least myself some confusion in the past.  Could we break
> > this into two distinct proposals (one for mobile smartphones, one for
> > WAP) to clarify the discussion?
>
> > I'm going off the list currently shown here:

> >http://wiki.opensocial.org/index.php?title=Spec_Changes#Proposals_for...

> ...
>
> read more »